در مقاله قبلی در خصوص نحوه ساده ترین احراز هویت در ساختار RODC صحبت کردیم و متوجه شدید که به صورت کلی RODC چگونه کار می کند و پسوردهای ما چگونه ذخیره می شوند. اما آیا همه چیز در شبکه دامین و اکتیودایرکتوری برای احراز هویت همین پسورد است ؟ در پاسخ به شما باید بگوییم خیر ، پسورد قسمتی از مسئله است و مسئله بعدی در احراز هویت و دسترسی به سرویس های ما مجوز دسترسی یا Ticket احراز هویت و دسترسی است. همانطور که قبلا هم در ITPRO گفته ایم ، پروتکل اصلی احراز هویت در اکتیودایرکتوری Kerberos است ، هرگاه شما بخواهید به یک سرویس در شبکه اکتیودایرکتوری متصل شوید و از آن استفاده کنید بایستی برای خودتان یک Ticket دسترسی داشته باشید. به این بلیط یا Ticket دسترسی به سرویس ها Ticket Granting Ticket یا TGT گفته می شود. این Ticket توسط یک سرویس به نام Key Distribution Center یا KDC ایجاد و صادر می شود که همیشه سرور Domain Controller ما در شبکه نقش KDC را بر عهده دارد و مدیریت Ticket های دسترسی هم بر عهده همین DC است.

ما فقط باید آنها را درخواست بدهیم ، در این مثال ما یک Ticket دسترسی را باید درخواست بدهیم که بتوانیم از سرویس File Server موجود استفاده کنیم. ما برای درخواست سرویس از فایل سرور نیاز به یک Ticket سرویس داریم ، زمانیکه این Service Ticket را دریافت کردیم می توانیم به سمت فایل سرور برویم و از آن درخواست سرویس کنیم. فایل سرور یا هر سرویسی که قرار است به ما سرویس بدهد با توجه به Ticket ای که به آن ارائه می کنیم به ما اجازه می دهد که به منابع دسترسی پیدا کنیم و یا اصلا اجازه دسترسی به ما نخواهد داد. اما این فرآیند زمانی است که شما در شبکه RWDC دارید ، زمانیکه شما در شبکه از RODC استفاده می کنید قضیه کمی متفاوت تر خواهد بود ، به تصویر زیر دقت کنید ، مراحل اضافه ای که باید در RODC برای انجام همین کار طی شود را مشاهده می کنید :

RODC چگونه کار می کند RODC چیست


تصور کنید که یک کاربر قرار است تغییراتی بر روی یک فایل متنی که درون فایل سرور قرار گرفته است ایجاد کند. برای اینکه بتواند اینکار را انجام بدهد بایستی یک Ticket سرویس برای فایل سرور تهیه کند. در گام اول کاربر درخواست Ticket خودش را به سمت RODC ارسال می کند. با توجه به مثال بالا و مقاله قبلی فرض می کنیم که در گام دوم هنوز RODC کاربر را نمی شناسد و باید اون را احراز هویت کند ، با توجه به اینکه RODC تیکت کاربر را ندارد که بخواهد آن را احراز هویت کند در گام سوم درخواست Ticket را به سمت RWDC ارسال می کند. RWDC تیکت مورد نظر را در گام چهارم بررسی می کند و در مرحله پنجم با توجه به صحت داشتن اطلاعات کاربر Ticket دسترسی را صادر و به سمت RODC ارسال می کند ، اگر یک DC معمولی در اینجا داشتیم ، اینجا همان زمانی بود که کاربر Ticket را دریافت می کرد اما در اینجا ما یک RODC داریم. در اینجا RODC متوجه می شود که یک Ticket دسترسی به صورت موفقیت آمیزی ایجاد شده است و پسورد کاربر مورد نظر نیز در پایگاه داده RODC وجود دارد حالا RODC یک حقه کوچک را بکار می برد. در مرحله ششم RODC به کاربر مورد نظر اعلام می کند که Ticket درخواستی شما نامعتبر است و اشتباه وارد شده است.

در همین حین کاربر همه درخواست های قبلی خودش را کنار می گذارد و همه موارد را از ابتدا شروع می کند که این مرحله هفتم از کار می شود. اینبار در مرحله هشتم کاربر مجددا درخواست Ticket می دهد اما اینبار RODC او را احراز هویت می کند و به وی Ticket دسترسی را ارائه می کند. با توجه به اینکه کاربر همچنان درخواست دسترسی به فایل سرور را دارد مجددا یک Ticket جدید ایجاد می کند و آن را به سمت RODC در مرحله نهم می فرستد. اینبار RODC توانایی خواندن Ticket احراز هویت کاربر مورد نظر را دارد و به سادگی توسط RODC احراز هویت می شود و Ticket دریافت می کند. البته توجه کنید که اینبار RODC محاسبات جدید Ticket را انجام می دهد و Ticket ای ویژه RODC تهیه و توزیع می کند که در مرحله دهم بصورت کامل قابل مشاهده است. حالا کلاینت Service Ticket خودش برای احراز هویت و استفاده از خدمات فایل سرور را دارد. خیلی راحت Ticket را بر می دارد و به سمت فایل سرور در مرحله یازدهم ارسال می کند و در نهایت دسترسی های لازم را دریافت می کند.

دچار ابهام شدید ؟ اشکالی ندارد این امر کاملا طبیعی است ، کمی صبر کنید و فکر کنید و مجددا مقالات را ابتدا مرور کنید ، سعی کنید این مقالات را با پارک ارم مقایسه کنید ، آنجا هم شما باید ابتدا بلیط خریداری کنید و بلیط ها را به مسئول دستگاه بدهید و از خدمات استفاده کنید. هر چیزی را می توانید با اینگونه مثال ها بهتر درک کنید. اما ای تقریبا کلیات روشی است که احراز هویت در RODC انجام می شود. البته تکنیک هایی وجود دارد که بتوانید برخی موارد احراز هویتی را به RODC بسپارید که از آن جمله می توان به Pre-Populate کردن آنها اشاره کنیم. به هر حال فراموش نکنید که RODC برای شعبات و نمایندگی های کوچکی که شما ریسک امنیتی نمی خواهید داشته باشید و از طرفی تیم پشتیبانی قوی ندارد یا اصلا هیچکس به این عنوان در محل حضور ندارد و یا در جاهایی که تعداد کلاینت ها بسیار کم است استفاده می کنید. امیدوارم مورد توجه شما قرار گرفته باشد. ITPRO باشید